I was a bit bored, so I did a quick mockup of the functionality by modifying the rendered Riot-web HTML for a message, just to see how it could look without anything more than a change in the allowed tag list.

I'm getting myself into the habit of queuing things into the FCP queue:

@mscbot fcp merge

Team member @turt2live has proposed to merge this. The next step is review by the rest of the tagged people:

• @KitsuneRal
• @anoadragon453
• @ara4n
• @dbkr
• @erikjohnston
• @richvdh
• @turt2live
• @uhoreg

No concerns currently listed.

Once at least 75% of reviewers approve (and none object), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

I am torn - on one hand, i really like the idea. on the other hand, i can see it being quite painful for those (e.g. Riot/iOS and Riot/Android and Seaglass) who are wrapping their own HTML renderer currently. And as @ananace quite rightly notes in the MSC, it does collide with #1767, which in theory could provide equivalent behaviour without depending on HTML to do it, and be more flexible in terms of allowing all sorts of different content/fallbacks to be togglable on & off.

What do others think?

my perspective is that MSC1767 is a great thing we should definitely do, however in the interest of progress we should shove this one through. The spec does not have a requirement on any of the HTML rendering, it just leaves it as a strong recommendation. This does technically mean that implementations could just add support if they wanted to without the spec, however this seems trivial enough to just merge into the spec's recommendation.

I also realized that I forgot to mention that one difference between this MSC and MSC1767 is that <details> would also support recursive usage - as well as the mentioned act of just using it multiple times in a single message.

As a small example of how that could be used for bot responses; (here as an imaginary message in response to some kind of monitoring query - or a notification)

<details>
  <summary>Host: <b>UP</b>, CPU: <b>CRIT</b>, Load: <b>WARN</b></summary>
  <b>CPU</b>: 100%<br/>
  <b>Load</b>: 15.04 7.4 4.2<br/>
  <b>RAM</b>: 24%<br/>
  <details>
    <summary><b>Disk</b>: 20%</summary>
    <ul>
      <li><b>/</b>: 12% 500GB</li>
      <li><b>/home</b>: 24% 1TB</li>
      <li><b>/var/log</b>: 74% 32MB</li>
    </ul>
  </details>
</details>

I agree with @turt2live in that I don't want to block this on extensible events like so many other things.

We shouldn't block clients from using this just because some have chosen technologies which make ti difficult to implement.

I, too, am torn on this. I fully see the value of that tag but, aside from overlapping (I wouldn't say "colliding") with extensible events, this tag only appeared in HTML5 (I know, I know...) and, as far as I can see, is not supported by IE (Update: Edge can do it, and I wouldn't look at the "old" IE as a reference anymore) . Most shamefully, HTML5 is not represented in the "Supported HTML subset" for rich text in Qt5 either, which means that - on top of poor things @ara4n mentioned - Nheko, Spectral, and Quaternion will have to go through unusual pains to render <details>.

With that said, the fallback is pretty clear: stripping the <details> tag and the <summary> contents entirely allows to still properly render the message. It's probably worth it to add this consideration to MSC.

One alternative to consider is to allow an attribute in m.room.message events that advises clients to render those events initially "collapsed" with a given content shown instead. This would emulate <details> functionality even if HTML is not used at all.

I, too, am torn on this. I fully see the value of that tag but, aside from overlapping (I wouldn't say "colliding") with extensible events, this tag only appeared in HTML5 (I know, I know...) and, as far as I can see, is not supported by IE. Most shamefully, HTML5 is not represented in the "Supported HTML subset" for rich text in Qt5 either, which means that - on top of poor things @ara4n mentioned - Nheko, Spectral, and Quaternion will have to go through unusual pains to render <details>.

OOI, is there a way of implementing similar behaviour that is easier in Qt5? If not then I'd be tempted to allow this and hop/assume that future Qt version start supporting <details> and that they can fallback fine in the mean time.

OOI, is there a way of implementing similar behaviour that is easier in Qt5? If not then I'd be tempted to allow this and hop/assume that future Qt version start supporting <details> and that they can fallback fine in the mean time.

Not really. The best way to emulate this in Qt would probably be parse HTML (ew), find the <details> block and separate it into its own widget/QML-component that expands on clicking. Alternatively, it might be possible to replace <details> with a generic <div> and attach some CSS+JS to it that would expand it.

Regarding "if not" - well, the trouble is that the basic HTML subset used by Qt for simple markup inside its widgets (as opposed to full-blown web-pages that can be displayed using Qt Web Engine, which is a wrapper around Chromium) is considered a thing in itself that "happens" to be a subset of HTML4. How much they would even want to update this basic HTML engine is beyond my knowledge. In a lucky case, Qt 6 will have it, almost surely not in 6.0 though. As it stands, I'm preparing to resort to one of the methods from the previous paragraph; however, since a similar trouble occurs across a few platforms, I wonder how much it's worth it.

I just wanted to chip in that I work in a few communities that make heavy use of content warnings, and a feature like this would be perfect for that usecase. The current alternative would be using spoilers and just add text like (CW: some content warning) before, which isn't a super intuitive way of doing it.

A feature like this that makes it intuitive to add content warnings would be super helpful, and greatly appreciated (especially if clients starting selling it as content warnings, which I think could have a great effect for normalizing cws across the ecosystem, like on masto, but that might be too much to ask for :p )

To follow up on my own whinings on the topic - I ended up making the HTML parser (with whichever tools Qt provides) in Quaternion; it's (hopefully) generic enough to (hopefully) be reused across C++/Qt ecosystem (and Qt 6 apparently has all the necessary ingredients), so it unblocks more than just myself. Moreover, the actual hands-on experience on converting between Matrix and Qt subsets tells me that conversions/wrappers of that kind are not terribly bad; so I added my tick to this.

Can we PLEASE get this to FCP? I don't believe there are any concerns outstanding.

🔔 This is now entering its final comment period, as per the review above. 🔔

The final comment period, with a disposition to merge, as per the review above, is now complete.

merged 🎉